hiroshi-cl
commented
4 years ago 1つだけコメントしておきます バージョンは3が良さそうです https://github.com/icpc-jag/rime/blob/master/setup.py#L5
Open not522 opened 4 years ago
hiroshi-cl
commented
4 years ago 1つだけコメントしておきます バージョンは3が良さそうです https://github.com/icpc-jag/rime/blob/master/setup.py#L5
not522
commented
4 years ago v2がちゃんとリリースされてないので迷ったんですが、v2をスキップしてv3にしますかね。
nya3jp
commented
4 years ago 長い間コントリビュートしていない身ですが、とりとめもなく考えていたアイデアを投下します。
事実上 Rime は独立したビルドシステムを提供しています。しかしビルドシステムというのは一般に複雑になりがちで、現状の Rime 内部の複雑性の大部分はここから来ていると思っています。また、Rime が想定している "自然な" ユースケースのみの利用であれば設定ファイル内のコードの記述量は最低限で済みますが、少しでもそこを外れようとすると (例えばユニットテストを書きたい等) プラグインを書く必要が出てきて、プラグインを書くためには Rime 内部の理解が必要になり、ハードルが著しく上がります。
機能拡張をするのが難しいというのはかなり大きな問題だと思っています。今日ではプログラミングコンテストの形式もいろいろあるので Rime がフィットしないケースも多いでしょう。問題文や入出力ファイルを同じリポジトリで管理してデプロイも自動化したいというのはコンテスト運営に関わったことのある全ての人が思うことだと思いますが、そういったことも機能拡張の難しさによって阻害されていると感じます。
なので、もし私が Rime をフルスクラッチでやり直すのであれば、別の既存のビルドシステムのルールセットとして書き直すと思います。
問題はどのビルドシステムを採用するかです。作問者の環境が Windows/Mac/Linux とバラバラなことも多いので、Make のように実行コマンドを直接記述するものよりはある程度抽象度をもったルールを書けるものがよいだろうとは思っています（なお Rime の前身は Makefile + perl で書かれており、とてもメンテナンスできるものではありませんでした）。未だにデファクトスタンダード的なビルドシステムは無いと思っていますが、少なくとも Rime が最初に書かれた当時に比べて選択肢は増えています。
候補として考えていたのはこんなところです:
元の方向性 (Rime v3) とは結構違いますが、どうでしょう。
not522
commented
4 years ago ビルドシステムを提供することで内部が複雑になってしまっているというのはその通りだと思います。既存のビルドシステムの使用で懸念しているのは以下の2点です。
1についてはPythonのままで移行出来る方が楽だろうと考えています。将来的に完全な作り直しを目指すにしても、v3で既存コードのリファクタリングがされてある方が開発しやすいと思います。
2についてはビルドシステムをあまり多用したことがないのでよく分かっていないんですが、ユーザの学習コストが高いのではないかと思ってます。ただ、デファクトスタンダードがあるのならば、学習コストを払うのはユーザにとって将来的にメリットになる可能性が大きいので許容できると思います。
拡張性をどの程度持たせておくかは難しいところですが、あまりに柔軟にしようとすると設計が複雑になってしまいますし、大部分のユースケースがカバーされていれば十分ではないかと思います。極端に変わった形式に対してはRimeとは独立したツールを開発した方が楽だろうと思っています。設定ファイルをJSON等に変更することで、別のツールとの組合せもやり易くなるだろうと思います。
現状としては既存コードのリファクタリングを優先するべきかなと思っています。既存のビルドシステムの導入は実際うまくいくのかよく分からないので、やるとしたらコンパクトな叩き台から始めるべきかなと思います。
nya3jp
commented
4 years ago not さんの2点の懸念は妥当だと思います。既存のビルドシステムに Rime のワークフローが馴染むかどうかは実際に試してみないと分からないところもあり、言い出した手前、デモくらいは書いてみようかなぁと思います。
既存コードのリファクタリングは良いことだと思います。プラグインの削除は妥当な方向性だと思いますし、またたとえばコードを複雑にしている元凶の一つであろう task graph は Python 3 の async/await で置き換えられると思います。
not522
commented
4 years ago async/awaitはかなり使いたいんですが、Python2を切り捨てるのはまだ時期尚早に思えます。なので、asyncioもどきを作って将来的（5年後くらい？）な移行を目指すのかなぁと思っています。とはいえ具体的な実装は固まってないので、これもデモくらいから始めるべきですね。
Rimeの設計を大幅に見直す検討をしています。特にアーキテクチャが複雑すぎて機能追加が難しくなっている点を解決したいと思っています。 参照 : https://github.com/icpc-jag/rime-plus/issues/9
（参考） 最近よく使われている競プロツール
他の作問支援ツール
以下の方針は個人的に考えているもので、開発陣の総意ではありません。コメントで自由に意見をください。
まず、rime-plusでの議論に沿って個人的に考えている解決案を書きます。
Rime+でほぼカバーされているのでは？これ以上特殊なジャッジに対応する必要はなさそう。
これはその通りでもっとシンプルに書き直した方が良い。とはいえ並列実行をするためにはそれなりに工夫が必要。
移行済み。
JSON等に移行しましょう。TOMLも良い感じに見えます。
GitHub Actionsで完結するようにすると良い感じになるはず。
Pythonでも型を書けるようになったので多少はマシな状況になった？
GitHub Actionsで緩和されるはず。
とりあえずRime+で十分？
最近はWSLも出たので現状のままでも大きな問題はないはず。
makeに任せてしまうというのは並列実行を考えると魅力的ですが、可読性が落ちるのではと懸念しています。
上記を踏まえて、以下のような方針を検討しています。
元のコードをそのまま活かせるメリットは大きいと思います。
pipでインストールするようになったので、pluginを追加するより本体に機能追加をしてもらう方がやりやすいと思います。
JSONなら外部ライブラリなしで使えるというメリットはありますが、TOMLの方がコメントも書けるなど便利になる可能性はあります。 外部ライブラリを極力減らすことで、pipインストールを上手くできない人が直接Rimeのソースコードを叩いて実行できるようになるメリットはありましたが、そもそもその機能が知られていない上、他でも（ https://github.com/icpc-jag/rime/issues/69#issuecomment-625162561 ）外部ライブラリを使う話が出ているのであまりこだわる必要はないと思います。
Google DocsやGitHubで問題文テンプレートを準備し、サンプルや制約の値などを自動的に挿入する機能を追加したいです。 例えば、library-checker-problemsは同じような形式になっています。 https://github.com/yosupo06/library-checker-problems/blob/master/sample/aplusb/task.md
現状のRimeだけでは作問フローが完結せず、他のサービスに依存している面がありました。例えばJAGではPukiWiki・Google Docs・Werckerを使っています。これをRime+GitHubで完結するように設計することで、導入を楽にしたいと思っています。一方、Google Docsなどと連携することでより便利になる可能性もあるので、（pluginではなく）追加のスクリプトなどで対応できるようにしたいと思います。
この方針で試験的に書き直しを進めています。現状はpluginを廃止し機能は本体に取り込み、設定ファイルをJSONに書き直している途中です。
https://github.com/not522/rime/tree/v2