La plateforme fast_xor est répertoriée comme :mri. Cependant, ce gem semble nécessiter des extensions C, mais il n’est pas spécifique à MRI : discourse/Gemfile at 0c7eaa57b26a22b0d0f85957ce0720be748d1fe6 · discourse/discourse · GitHub
J’ai également confirmé que cela fonctionne sur la dernière version de TruffleRuby.
Pourriez-vous mettre à jour la plateforme vers :ruby ?
À titre de référence, voici une liste des significations des différentes plateformes :
Bien sûr, je m’en suis justement occupé. Il en reste quelques-uns dont je ne suis pas certain ; que dois-je faire avec eux ? (byebug, ruby-prof, better_errors, rbtrace, gc_tracer, stackprof, memory_profiler)
Cela dit, nous sommes complètement bloqués sur Truffle jusqu’à ce que mini_racer fonctionne, comme indiqué ici :
https://github.com/oracle/truffleruby/issues/1827
Discourse n’est pas vraiment fonctionnel si vous ne pouvez pas convertir le Markdown en HTML côté serveur.
Merci, DEV: change platform mri to platform ruby on some gems · discourse/discourse@620c223 · GitHub semble bon.
unicorn ne fonctionnera probablement pas sur TruffleRuby car il repose sur fork, mais il s’installe en réalité.
Discourse peut-il fonctionner avec Puma à la place ? Une configuration spécifique est-elle nécessaire ?
Il y a quelques autres que j’ai laissés et dont je ne suis pas sûr. Que dois-je faire avec eux ? (byebug, ruby-prof, better_errors, rbtrace, gc_tracer, stackprof, memory_profiler)
Oui, tous semblent très spécifiques à MRI (jusqu’à ce qu’ils commencent à prendre en charge différents backends), donc le mieux est de les marquer avec platforms: :mri pour l’instant.
better_errors pourrait fonctionner, mais binding_of_caller ne prend pas encore en charge TruffleRuby.
Ces gems semblent aussi être principalement des outils de débogage et de performance qui ne semblent pas nécessaires pour faire fonctionner l’application.
Oui, nous devons examiner mini_racer.
Je me demande, dans ce contexte, pourquoi le JavaScript est utilisé pour rendre le Markdown ?
Pour s’assurer que le résultat est exactement le même que lorsqu’il est exécuté dans le navigateur du client ?
En développement, une simple commande rails server utilise Puma.
Oui. Maintenant que wasm existe, cela pourrait être une solution, mais cela nécessiterait un changement très important pour maintenir la possibilité d’étendre les fonctionnalités via des plugins comme aujourd’hui.
wasm serait certainement exclu ici ; la charge utile serait beaucoup plus lourde. Il y a de nombreux problèmes de sécurité liés à son exécution correcte avec les CSP (et des préoccupations concernant les CORS). L’implémentation de markdown.it est extraordinairement rapide et extensible, permettant de nombreux plugins et bénéficiant d’un vaste écosystème existant.
Voici un peu plus de contexte sur mini_racer. Dès le jour 0 chez Discourse, nous avons insisté sur un pipeline unique pour traiter le markdown, ce qui a complètement éliminé une classe très problématique de bugs que j’avais rencontrés chez Stack Overflow, où le serveur et le client parlaient des dialectes légèrement différents. Pour Discourse, c’est encore plus important car les plugins peuvent modifier le pipeline. Par exemple :
est implémenté dans un plugin (analyse de [])
Nous bénéficions de plusieurs fonctionnalités « qualité de vie » en utilisant Unicorn et en nous appuyant sur le forking, voir :
En particulier, nous surveillons et gérons un processus fils Sidekiq depuis le processus maître.
Mais… Truffle n’a pas de GIL. Puma est déjà présent dans le Gemfile une fois que mini_racer fonctionne. Nous pourrions collaborer sur une configuration Truffle économe en mémoire qui maintient Sidekiq et Puma dans le même processus. Ou les utilisateurs pourraient simplement lancer un processus Sidekiq manuellement. Puma peut certainement fonctionner ; nous utilisons largement Rack.hijack, mais cela est déjà implémenté dans Puma, Unicorn et Passenger.
mini_racer 0.6.3 fonctionne maintenant sur TruffleRuby 