samunohito / kanaria Goto Github PK

converter周りのドキュメンテーションでコケてるのを修正する。
ConverterFactoryで生成したインスタンスを束縛しろってエラーが出てるので、そのとおりにする。

前はうまく行っていたんだが…なんだこれ。

cargo install kanaria　…とかでできるようにする。

Gradleからサブプロジェクトたち向けのバイナリビルドを全部制御できるようにする

https://github.com/samunohito/kanaria/actions/runs/5706585882

Unicode全部となると膨大なのでひとまずJIS非漢字に属するやつだけでも判定できるようにする。
JIS非漢字に属さない記号も判定したくなったら、そのときは追加で…。

すごくこざっぱりしているので、なんとかしないと…
その前に、速度改善と変換処理の強化か？強みがなさすぎて書くことがない…

変換速度改善の第二弾と銘打ちたかったが…下記の理由により方針変更。

・速度改善が第一弾（#3）レベルで頭打ちになってしまった
・もともと多言語対応を視野に入れていた（第一弾の影響でC#独自の構文が増え、移植が困難に）

…ということから、C#はDllImport等でネイティブ層の機能をラッピングした物を用意し、
処理の根本はネイティブ（Rust）に移動する。

/docsでRustdocを公開しようとしても上手く行かなかった残滓を削除する。重い。

テストは書いてあるけど、自動ではない。
有効活用するため是非とも用意したい。

Jenkinsあたりを想定。リリースの用意までやってくれそうだし…

NuGet経由で入れられるかどうかの検討。
どうやってネイティブDLLを抱き合わせるかが一番の鍵だと思う。

考えられる方法としては以下。上から順にベストだと思ってるもの。

1. ラッパーDLLにネイティブDLLを埋め込んで、そのまま使える
2. ラッパーDLLにネイティブDLLをリソースで持たせて、無ければ所定の場所に吐き出して読み込む
3. ラッパーDLLにネイティブDLLを一切持たせず、ユーザに配置してもらう
   （ない場合は例外でDL先を明示できれば尚良し）

NuGet対応の最中に見つけた問題。

Utils配下のテストを忘れていたのでテストを作ったが、
AsciiUtils.IsWideAscii('漢')でtrueが帰ってくるという珍事に見舞われた。
漢字なのでfalseが期待結果のはずだが…。

Rust側でも同じ内容のテストを追加で実行してみたが、こちらは問題なし。
上記の内容でもfalseがきちんと返却されていた。

VB.netのStrConvやKanaxsと比較すると、変換速度に難がある。
少なくとも同程度まで改善しないと同じ土俵にすら立てない。

extern_cのプロジェクトをビルドして出てきたものをJNIを通じてJavaから操作できるようにする。

C#側のUcsStringで実装しているメソッドチェーンによる変換先指定をRustに逆輸入する。

変換処理だけでなく、判定処理も追加して出来ることを増やす。

#18 が実現できないと何もできないけど、多分できるので先に切っておく。
Mavenのリポジトリに追加できたらいいなという願望…。