On dirait que c’est un problème inévitable, puisqu’on est obligé de mettre la logique dans du YAML.
L’article ci-dessus semble proposer plus ou moins cette réponse, mais j’ai aussi l’impression que si l’on remplaçait la partie script par Dagger, ce serait peut-être la bonne solution.
« Ne laissez pas GitHub Actions gérer la logique ; contrôlez directement les scripts, et faites en sorte qu’Actions se contente d’appeler ces scripts. »
Après le rachat de Bun par Claude, les bonnes nouvelles continuent de tomber. Cela devrait lui permettre de se consacrer au projet de manière plus stable.
On ne voit pas vraiment de modèles TTS open source prenant en charge le coréen.
J’avais entendu dire que Kokoro-82M, publié il y a quelque temps, prenait bien en charge le coréen, mais aussi que la qualité n’avait pas l’air très bonne,
et en cherchant rapidement, j’ai vu qu’on pouvait aussi en créer et utiliser avec GPT-Sovits, ou obtenir des résultats plutôt corrects avec quelque chose comme Edge-TTS.
Ces temps-ci, avec le vibe coding, je me dis qu’en le combinant avec Whisper il y aurait sûrement moyen de faire quelque chose d’intéressant, mais je n’ai pas d’idée haha
Dans l’embarqué, on code en tenant compte jusqu’à la taille des lignes de cache du matériel. La question, c’est jusqu’où un programmeur peut pousser l’optimisation extrême au niveau du langage, ainsi que les performances de la bibliothèque standard et du compilateur. De toute façon, comme les deux prennent en charge le bas niveau, la légère différence d’overhead sera probablement négligeable. Donc je ne pense pas que ce soit un débat très pertinent… Si une optimisation extrême est nécessaire, une intervention humaine finit de toute façon par s’imposer. Les compilateurs ne sont pas aussi parfaits qu’on pourrait le croire.
Évidemment, le niveau est différent quand c’est utilisé par quelqu’un qui a des connaissances en composition et de la créativité, plutôt que par le grand public qui clique juste sur un bouton, non ?
On dirait que c’est un problème inévitable, puisqu’on est obligé de mettre la logique dans du YAML.
L’article ci-dessus semble proposer plus ou moins cette réponse, mais j’ai aussi l’impression que si l’on remplaçait la partie script par Dagger, ce serait peut-être la bonne solution.
« Ne laissez pas GitHub Actions gérer la logique ; contrôlez directement les scripts, et faites en sorte qu’Actions se contente d’appeler ces scripts. »
Astro, c’est un retour aux fondamentaux du web
Sortie d’Astro 3.0
Astro : déployer le minimum de JavaScript
Après le rachat de Bun par Claude, les bonnes nouvelles continuent de tomber. Cela devrait lui permettre de se consacrer au projet de manière plus stable.
C'est une bonne nouvelle.
C’est bien, la gestion de l’historique des conversations se fait à la fois avec le FTS et avec des vecteurs.
Redis, c’est bien.
Article connexe - https://fr.news.hada.io/topic?id=25859
C’est un texte plein de perspicacité, je continue à le lire et à le relire.
https://ywc.life/posts/vercel-react-best-practice
Je l’ai traduit en entier.
J’ai l’impression que les changements de notre époque vont beaucoup, beaucoup trop vite T_T
On ne voit pas vraiment de modèles TTS open source prenant en charge le coréen. J’avais entendu dire que Kokoro-82M, publié il y a quelque temps, prenait bien en charge le coréen, mais aussi que la qualité n’avait pas l’air très bonne, et en cherchant rapidement, j’ai vu qu’on pouvait aussi en créer et utiliser avec GPT-Sovits, ou obtenir des résultats plutôt corrects avec quelque chose comme Edge-TTS.
Ces temps-ci, avec le vibe coding, je me dis qu’en le combinant avec Whisper il y aurait sûrement moyen de faire quelque chose d’intéressant, mais je n’ai pas d’idée haha
Dans l’embarqué, on code en tenant compte jusqu’à la taille des lignes de cache du matériel. La question, c’est jusqu’où un programmeur peut pousser l’optimisation extrême au niveau du langage, ainsi que les performances de la bibliothèque standard et du compilateur. De toute façon, comme les deux prennent en charge le bas niveau, la légère différence d’overhead sera probablement négligeable. Donc je ne pense pas que ce soit un débat très pertinent… Si une optimisation extrême est nécessaire, une intervention humaine finit de toute façon par s’imposer. Les compilateurs ne sont pas aussi parfaits qu’on pourrait le croire.
Je me demande si le coréen est bien pris en charge.
En moyenne, je ne sais pas quelle langue est la plus rapide, mais j’ai l’impression que c’est le C++ qui présente la plus grande dispersion.
Et la première photo ressemble vraiment à une scène d’un film de genre post-apocalyptique.
(Le niveau en code = le strict minimum pour être à table) T_T
Vous ne l’avez pas fait exprès, n’est-ce pas ? Hé hé.
Zig n’est pas mauvais non plus... TT
Évidemment, le niveau est différent quand c’est utilisé par quelqu’un qui a des connaissances en composition et de la créativité, plutôt que par le grand public qui clique juste sur un bouton, non ?
Le site original lui-même est déjà excellent, mais il n'existe toujours pas encore de traduction en coréen.