rsk0315

元々自分のローカル用に実装していたものでしたが、issue に上がっていたので PR (https://github.com/online-judge-tools/oj/pull/915) を出してみました。オプションのインタフェースなどには議論の余地があると思うので、何かあれば言っていただけるとうれしいです。

`oj-bundle` でライブラリを運用することを考えると、この種のマクロ自体が不要な気もします。（いま思いつかないだけで、それっぽい理由があるかもしれません？）

一般的な解決が不可能というのはそうですね。 以前使っていた例は、次のような感じでした。 テスト側： https://github.com/rsk0315/library/blob/245b9ba52a0c0a2067cfbec9e007f2ea3e326710/test/aoj_DPL_1_D.test.cpp#L3-L6 ライブラリ側： https://github.com/rsk0315/library/blob/245b9ba52a0c0a2067cfbec9e007f2ea3e326710/DataStructure/wavelet_matrix.cpp#L14-L17

別の private リポジトリにミラーでテストケースを置いて、何らかのトークン経由でそれを参照したり、適宜落としてそっちに push する感じにする？

気づいたけど、`#[test]` 側がわざわざカスタムジャッジの設定をしようとしてるのはおかしいんだよね そもそも `Fn(String) -> String` でやりとりしてるのは面倒だなぁ 入出力を一々やってもうれしくなくて、テストケースは予めパースしてしまって json かなにかにしておきたい 諸々を考えると、_testcases.toml_ で管理するんじゃなくて、`Vec)>` みたいなのを置いておくとうれしそうなような

``` static AOJ_PROBLEM_LIST: Vec Json)> = vec![ "0000", &parse_aoj_0000, "DSL_2_B", &parse_aoj_dsl_2_b, // ... ]; ``` とかしておいて、？

``` trait Solver { type Input: Deserialize + Serialize; const TL: Duration; const PROBLEM_ID: &str; fn parse_input(input: String) -> Input; fn parse_output(output: String) -> Output; fn solve(input: Input) -> Output;...

で、download したときは `parse_input` を使って JSON にでもしておく。 verify のときは `serde` で `Input` / `Output` に変換して、`solve` / `judge` で判定する

面白そうなんだけど、`parse` と `judge` は各問題ひとつなのに対して、`solve` はひとつとは限らないんだよねえ verifier 側からは ``` #[test] fn verify_ds() { verify(AojXxxxJudge, aoj_xxxx_solver1::); verify(AojXxxxJudge, aoj_xxxx_solver2::); verify(AojYyyyJudge, aoj_yyyy_solver::); } ``` みたいにできるとよさそ `judge()` は ``` fn judge(input: Input, jury: Output, solver:...

https://github.com/rsk0315/library-rs/pull/21 こんな？ mod じゃなくて crate にするべきだった？