Bah, si je suis honnête, me faire plaisir c'est 80% de la motivation de ce projet ;) J'ai pu (et je peux) jouer avec du code bas niveau, de l'assembleur x86, x64, RISC-V, ARM64 et ARM32, les différentes ABI C. Et bientôt PowerPC :)
Cela dit, ma motivation initiale c'était d'utiliser Raylib sans tout wrapper. Certes, node-raylib existe, et c'est ce que j'ai utilisé au début... Mais un certain nombre de bugs existent, et j'ai eu pas mal de crashs, ainsi que pas mal de fonctions inutilisables ou toujours pas wrappées à ce jour. A ce moment, je me suis dit "tiens, pourquoi pas utiliser node-ffi". J'ai converti le code que j'avais, j'ai lancé, les perfs étaient bien plus catastrophiques qu'attendu... Et Koffi est né :)
Et puis, node-ffi, libffi, dyncall , toutes ces choses existent déjà et ont pas mal d'utilisateurs, a priori il y a un public et un besoin. On verra bien !
Bien évidemment, une autre possibilité existe, c'est de générer un binding de manière automatisée. Émettre du C, qui utilise N-API et le compiler en live, c'est simple dans l'idée. Si l'écosystème C était moins arachaïque, on compilerait du code de binding dynamiquement et facilement (sans avoir de souci avec certaines plateformes, de problèmes avec les linkers, etc), et ça serait plus performant. Mais l'écosystème étant ce qu'il est, ce n'est pas si facile et ça pose tout un tas de problèmes, largement liés aux nombreux arachaïsmes du C, de POSIX, de Win32, de macOS, etc.
[^] # Re: Performance
Posté par Koromix . En réponse au journal Koffi, un paquet simple, complet et rapide de FFI C pour Node.js. Évalué à 3.
Bah, si je suis honnête, me faire plaisir c'est 80% de la motivation de ce projet ;) J'ai pu (et je peux) jouer avec du code bas niveau, de l'assembleur x86, x64, RISC-V, ARM64 et ARM32, les différentes ABI C. Et bientôt PowerPC :)
Cela dit, ma motivation initiale c'était d'utiliser Raylib sans tout wrapper. Certes, node-raylib existe, et c'est ce que j'ai utilisé au début... Mais un certain nombre de bugs existent, et j'ai eu pas mal de crashs, ainsi que pas mal de fonctions inutilisables ou toujours pas wrappées à ce jour. A ce moment, je me suis dit "tiens, pourquoi pas utiliser node-ffi". J'ai converti le code que j'avais, j'ai lancé, les perfs étaient bien plus catastrophiques qu'attendu... Et Koffi est né :)
Et puis, node-ffi, libffi, dyncall , toutes ces choses existent déjà et ont pas mal d'utilisateurs, a priori il y a un public et un besoin. On verra bien !
Bien évidemment, une autre possibilité existe, c'est de générer un binding de manière automatisée. Émettre du C, qui utilise N-API et le compiler en live, c'est simple dans l'idée. Si l'écosystème C était moins arachaïque, on compilerait du code de binding dynamiquement et facilement (sans avoir de souci avec certaines plateformes, de problèmes avec les linkers, etc), et ça serait plus performant. Mais l'écosystème étant ce qu'il est, ce n'est pas si facile et ça pose tout un tas de problèmes, largement liés aux nombreux arachaïsmes du C, de POSIX, de Win32, de macOS, etc.