-
Notifications
You must be signed in to change notification settings - Fork 117
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Node.js向けのFFIを実装 #758
base: main
Are you sure you want to change the base?
Node.js向けのFFIを実装 #758
Conversation
This reverts commit ea809fb.
Ready for reviewとしてマークしました。 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
とりあえず一通り。
Tripletごとにパッケージ分けるのって避けれたりします?絶対にしんどいと思うので
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pythonと違ってJavaScriptは非同期がメイン(主観)なので、blocking APIは提供しなくてもいいと思います(個人の思想ですが)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NodeではないですがDenoだと例えば標準ライブラリの各機能に対して同期版があったりします (e.g. Deno.readFile
に対してDeno.readFileSync
)。ただNodeでもそれをやるべきかというと微妙かもしれませんが。
@Hiroshiba #662 の観点から一言お願いします。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
絶対ないといけないとは思わない、とはいえ実装を拒む理由も特にない、って感じですかね!
webのjsならともかく、nodeを使う人のレベル感は割と高そうなので、非同期版のみでも大丈夫だと思います。
とはいえ別にあったらダメというわけでもない気がしました。トップレベルasyncが書けない場合があったりとか、何かと便利ではあると思うので。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-muslまでの差分は提供しなくてもいいと思います。
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
遅くなりましたが、概ね良いと思います!
lintに引っ掛かってる部分とコンフリクトについては、ご面倒であればこちらでやらせて頂ければと思っているのですが、どうでしょうか?
(追記) #761 対応もありました。StyleMeta
にtype
というものが追加されています。
ありがとうございます。自分で対応してみます。 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
概ね良いと言った手前ですがいくつか:
__dirname, | ||
"..", | ||
"..", | ||
"..", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"..", | |
"test_util", | |
"data", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
.gitattributesでlinguist-vendored linguist-generated
を設定した方がよいかも。
`npm test` でテストを行うことができます。 | ||
|
||
```console | ||
❯ npm test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
テスト前にcargo build -p test_util
が要るんじゃないかと思います。
(クリーンなリポジトリからvoicevox_core_node_apiだけビルドした場合、crates/test_util/dataは生成されない)
参考:
voicevox_core/.github/workflows/test.yml
Line 279 in 18aec9f
- run: cargo build -p test_util -vv # build scriptにより/crates/test_util/data/の生成 |
voicevox_core/.github/workflows/test.yml
Line 315 in 18aec9f
cargo build -p test_util -vv # build scriptにより/crates/test_util/data/の生成 |
npm test
内に仕込むのがいいかもしれませんが、どうやるかは私にはよくわからないです。なんかnpm-run-all2っていう、かつてのnpm-run-allのフォークがあるっぽい…?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"test": "run-s test:build-util test:ava",
"test:build-util": "cargo build -p test_util",
"test:ava": "ava"
npm-run-all2使うとこんな感じだと思います。
まぁ直列ならOS差は困るほどはないので、
"test": "cargo build -p test_util && ava"
でいいかも。avaにセットアップのHookがあるならそれでビルドしてもいいかも?
#![deny(clippy::all)] | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NAPI-RSの慣習だと思いますが、このリポジトリの場合はCIでやってるので不要かと思います。
voicevox_core/.github/workflows/test.yml
Lines 75 to 76 in 18aec9f
- run: cargo clippy -vv --all-features --features onnxruntime/disable-sys-build-script --tests -- -D clippy::all -D warnings --no-deps | |
- run: cargo clippy -vv --all-features --features onnxruntime/disable-sys-build-script -- -D clippy::all -D warnings --no-deps |
ClippyというのはVSCodeとかのエディタ上で動くので(もし設定されていなかったのであれば設定することをお勧めします)、少しうっとおしくなってしまうかと思います。
#![deny(clippy::all)] |
https://github.com/VOICEVOX/voicevox_core/actions/runs/9202752835/job/25313764046?pr=758 あ、なんかの依存の更新でCargo.lockのcbindgenのバージョンが上がったっぽいですね。このCIの直しかたは ❯ cargo xtask update-c-header です。 |
pub fn unload_voice_model(&self, voice_model_id: String) -> Result<()> { | ||
convert_result( | ||
self.synthesizer | ||
.unload_voice_model(&VoiceModelId::new(voice_model_id)), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
impl JsSynthesizer { | ||
/// `Synthesizer`をコンストラクトする。 | ||
#[napi(constructor)] | ||
pub fn new(open_jtalk: &JsOpenJtalk, options: Option<InitializeOptions>) -> Result<Self> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Onnxruntime
が追加され、Synthesizer
のコンストラクタに要求されるようになりました。
[dependencies] | ||
napi = { version = "2.16.0", features = ["napi4", "serde-json", "tokio_rt"] } | ||
napi-derive = "2.16.0" | ||
voicevox_core.workspace = true |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- featureとして
load-onnxruntime
とlink-onnxruntime
が追加されました。ただしPythonとJavaではload-onnxruntime
で固定です。Node.jsもそうすることになると思います。
voicevox_core.workspace = true | |
voicevox_core = { workspace = true, features = ["load-onnxruntime"] } |
/// `SupportedDevices`をコンストラクトする。 | ||
#[napi(factory)] | ||
pub fn create() -> Result<Self> { | ||
match SupportedDevices::create() { | ||
Ok(val) => Ok(JsSupportedDevices { | ||
supported_devices: val, | ||
}), | ||
Err(err) => Err(Error::from_reason(err.to_string())), | ||
} | ||
} | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
supported_devices
はOnnxruntime
のメソッドになりました。
} | ||
|
||
#[napi] | ||
impl JsSynthesizer { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Synthesizer
はOnnxruntime
のgetterを持つようになります。
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@takejohn お久しぶりです。 |
お願いします! |
@takejohn わかりました!ではこちらで進めさせていただきます。 @Hiroshiba これからの段取りについて、次の形を考えています。どうでしょうか?
あと正式リリースできる日が来たらNode.js APIを作った人として @takejohn さんのお名前も… あれ?どういう風な紹介になりますかね? |
方針良さそうに感じました!! お名前紹介の際は2人の名前を紹介する感じで良いかなと! |
内容
NAPI-RS を用いて Node.js 向けの FFI を実装します。
関連 Issue
ref #550
その他
#757 で Neon を使おうと思っていましたが、より開発が活発で情報が見つかる(と思われる) NAPI-RS を使うことにしました。