La plataforma fast_xor está listada como :mri. Sin embargo, este gem parece requerir extensiones en C, pero no es específico de MRI: discourse/Gemfile at 0c7eaa57b26a22b0d0f85957ce0720be748d1fe6 · discourse/discourse · GitHub
También he confirmado que esto funciona en la última versión de TruffleRuby.
¿Podrías actualizar la plataforma a :ruby?
Como referencia, aquí tienes una lista de los significados de las diferentes plataformas:
Claro, ya me encargué de esto. Quedan algunos otros que dejé y de los que no estoy seguro; ¿qué debo hacer con ellos? (byebug, ruby-prof, better_errors, rbtrace, gc_tracer, stackprof, memory_profiler)
Dicho esto, estamos totalmente bloqueados en Truffle hasta que funcione mini_racer según:
Discourse no funciona correctamente si no se puede convertir Markdown a HTML en el servidor.
Gracias, DEV: change platform mri to platform ruby on some gems · discourse/discourse@620c223 · GitHub parece correcto.
unicorn probablemente no funcionará en TruffleRuby porque depende de fork, pero de hecho se instala.
¿Puede Discourse ejecutarse en Puma en su lugar? ¿Se requiere alguna configuración para ello?
hay algunos otros que dejé de los que no estoy seguro, ¿qué debo hacer con ellos? (byebug, ruby-prof, better_errors, rbtrace, gc_tracer, stackprof, memory_profiler)
Sí, todos parecen muy específicos de MRI (hasta que comiencen a admitir diferentes backends), así que lo mejor es usar platforms: :mri por ahora.
better_errors podría funcionar, pero binding_of_caller aún no admite TruffleRuby.
Estas gems también parecen ser principalmente herramientas de depuración y rendimiento que no parecen necesarias para hacer funcionar la aplicación.
Sí, necesitamos revisar mini_racer.
Me pregunto, por contexto, ¿por qué se usa JS para renderizar Markdown?
¿Para asegurarse de que el resultado sea exactamente el mismo que cuando se ejecuta en el navegador del cliente?
En desarrollo, un simple rails server utilizará Puma.
Sí. Ahora que existe wasm, podría ser una solución, pero implicaría un cambio muy grande para mantener la extensibilidad mediante plugins como lo es hoy en día.
wasm definitivamente quedaría fuera de discusión aquí; la carga útil sería mucho más grande, hay un sinfín de problemas de seguridad relacionados con ejecutarlo correctamente con las políticas CSP (y preocupaciones sobre CORS). La implementación de markdown.it es espectacularmente rápida y extensible, lo que permite una gran cantidad de plugins y un ecosistema existente enorme.
Solo un poco más de contexto sobre mini_racer. Desde el día 0 en Discourse insistimos en tener un único pipeline para procesar el markdown; esto eliminó por completo una clase muy molesta de errores que experimenté en Stack Overflow, donde el servidor y el cliente hablaban dialectos ligeramente diferentes. Para Discourse esto es aún más importante porque los plugins pueden modificar el pipeline. Por ejemplo:
se implementa en un plugin (análisis de [])
Tenemos bastantes “mejoras de calidad de vida” que obtenemos al usar Unicorn y confiar en el forking, ver:
Específicamente, supervisamos y gestionamos un proceso hijo de Sidekiq desde el proceso principal.
Pero… Truffle no tiene GIL; Puma ya está en el Gemfile una vez que mini_racer funcione. Podríamos colaborar en una configuración de Truffle que conserve la memoria y mantenga Sidekiq y Puma en el mismo proceso. O la gente podría simplemente iniciar un proceso de Sidekiq manualmente. Puma definitivamente puede funcionar; hacemos un uso extensivo de Rack.hijack, pero eso ya está implementado en Puma, Unicorn y Passenger.
mini_racer 0.6.3 ahora funciona en TruffleRuby 