cargo-atcoderの代替品を作った

cargo-atcoder を使って Rust での AtCoder ライフを超快適にする

この記事で紹介されているcargo-atcoderの代替品としてcargo-competeを作りました。これを書いている時点でv0.5.0です。

インストール方法と使い方は日本語READMEを見てください。バイナリでの配布もしています。

cargo-atcoderで作ったパッケージをマイグレートするためにcargo compete migrate cargo-atcoderというコマンドも用意しています。

動機

• 自分用に作った競プロツールを腐らせるのがもったいなかった。cargo-competeはそれを流用して作った
• 以下で紹介する機能が欲しかった/捨てるのが惜しかった
  • cargo-atcoderに乗り換えることはそこそこ本気で考えていて、いくつかコントリビュートもしたが、自分用のものを用意した方が早そうと思った

機能

cargo-atcoderにはない機能として以下のものがあります。

• AtCoderのほかCodeforcesとyukicoderに対応

• AtCoderではDropboxからのダウンロードに対応

  ただし自分で認証したJSONをディレクトリに放り込んで..という形になります。

  

  問題ページをPDFで保存しておけば、航空機内でAtCoderができます。ただインターネットが使えないのもそうですが紙とペンを出すスペースがあるとも限らないので、低難易度の問題を解くのに留めたほうが良いでしょう。

• テストケースはこのようなYAMLとして保存され、手軽に編集できます。

  • matchがFloat: { .. }の場合、数値っぽい文字列は浮動小数点数として比較されます。サンプルケース取得時にそれっぽいキーワードとそれっぽい数値から自動で判定されます。
  • cases[].outは省略可能です。省略した場合REやTLEしない限りすべてのUTF-8の出力が通ります。
  • extendを使うことで大きな入出力データはテキストファイルにするということが可能です。「フルの」テストケースを取得するときはテキストファイルとして保存され、保存先がextendに書かれます。
  a.yml

  ---
  type: Batch
  timelimit: 2s
  match: Lines
  
  cases:
    - name: sample1
      in: |
        1
        2 3
        test
      out: |
        6 test
    - name: sample2
      in: |
        72
        128 256
        myonmyon
      out: |
        456 myonmyon
  
  extend:
    - type: Text
      path: "./a"
      in: /in/*.txt
      out: /out/*.txt
  

• 問題ページとファイルを開く機能

  問題ページをブラウザで開くのはもちろん、ソースコードと上記のテストファイルを任意のエディタで開くことができます。 (jqが必要です。無い場合はパッケージマネージャで入れるか、WindowsならGitHub Releases等からダウンロードして$PATH内に置いてください)

  compete.toml

  # Open files with the command (`jq` command)
  #
  # VSCode:
  # `["code", ..]`一発で記述できるだろうと思っていたがそうではなかった
  #open = '["bash", "-c"] + ["code -a " + .manifest_dir + " && code " + (.paths | map([.src, .test_suite]) | flatten | join(" "))]'
  # Emacs:
  #open = '["emacsclient", "-n"] + (.paths | map([.src, .test_suite]) | flatten)'
  

• ~~パッケージをワークスペースで管理し、~~ビルドキャッシュを共有

  AtCoderでは2020年のジャッジアップデートでRustが1.42.0にアップデートされ、39個のクレートが使えるようになりました。 また、サードパーティのクレートを含んだ実行バイナリをbase64でエンコードして提出する「バイナリ提出」もその是非はともかく今のところ明示的に容認されてます。しかしcargo-atcoderではコンテストに対応するパッケージ一つにつき一つのビルドキャッシュを使うため、クレートの数を控えるかコンテスト開始前にビルドを行っておく必要があるという問題がありました。

  cargo-competeではパッケージをワークスペースで管理することでこの問題を解決ししていました... v0.4.7までは。というのもワークスペースで管理していると、数百のパッケージがあったときにrust-analyzer等の開発ツールに負荷がかかってしまっていました。 (この924はwarningの個数です)

  

  v0.5.0からは.cargo/config.tomlでtargetディレクトリだけを共有し、各パッケージのワークスペースは分離されます。ただし各binのリネームは従来のままです。(e.g. src/bin/a.rs → abc170-a)

• コンテストへの参加登録

  コンテストの問題一覧が404の場合、コンテストの開始時間を見て開始してたら参加登録を試みます。

• AtCoder上のいくつかの古い問題に対応

  全部ではありませんが古い問題のうちいくつかのパターンに対応しています。

Q&A

cargo compete newが開始前のコンテストに使えない

cargo-competeではビルドキャッシュを共有する限り"warmup"が不要なため、問題が見えない場合に番号を推測するといった機能は付けてません。

cargo compete gen-binaryは?

今のところありません。バイナリ提出の場合resources/exec-base64-encoded-binary.rs.liquidにsource_codeとbase64のパラメータを与えたものが提出されます。ただしそれはファイルシステム上に置かれません。

ojやatcoder-toolsと併用することも、想定していないことはないですがバイナリ提出する人の人数を考えると共通集合は空に近いと考えているためです。

そもそも使い方がわからない

README-jaと--helpを見てわからなければ、Qiitaのコメント欄かGitterの部屋も立てたのでこちらかにでも。

使い方を誤ったときでも人間が解釈可能なエラーメッセージが発生するはずなので、「エラーが意味不明」のようなものでも報告していただけると幸いです。 不具合によるものかもしれないし、そもそも適切なメッセージが出ないのは不具合なので。