A plataforma fast_xor está listada como :mri. No entanto, este gem parece exigir extensões em C, mas não é específico para o MRI: discourse/Gemfile at 0c7eaa57b26a22b0d0f85957ce0720be748d1fe6 · discourse/discourse · GitHub
Também confirmei que isso funciona na versão mais recente do TruffleRuby.
Poderia, por favor, atualizar a plataforma para :ruby?
Para referência, aqui está uma lista dos significados das diferentes plataformas:
Claro, eu já resolvi isso. Existem alguns outros que deixei de lado e sobre os quais estou inseguro: o que devo fazer com eles? (byebug, ruby-prof, better_errors, rbtrace, gc_tracer, stackprof, memory_profiler)
Dito isso, estamos totalmente bloqueados no Truffle até que o mini_racer funcione, conforme:
https://github.com/oracle/truffleruby/issues/1827
O Discourse não funciona adequadamente se não for possível converter Markdown em HTML no servidor.
Obrigado, DEV: change platform mri to platform ruby on some gems · discourse/discourse@620c223 · GitHub parece bom.
O unicorn provavelmente não funcionará no TruffleRuby porque depende do fork, mas na verdade ele é instalado.
O Discourse pode rodar no Puma? Há alguma configuração necessária para isso?
há alguns outros que deixei de lado e sobre os quais tenho dúvidas; o que devo fazer com eles? (byebug, ruby-prof, better_errors, rbtrace, gc_tracer, stackprof, memory_profiler)
Sim, todos parecem ser muito específicos do MRI (até que comecem a suportar diferentes backends), então o ideal é usar platforms: :mri por enquanto.
O better_errors pode funcionar, mas o binding_of_caller ainda não suporta o TruffleRuby.
Esses gems também parecem ser principalmente ferramentas de depuração/desempenho que não parecem necessárias para fazer o aplicativo funcionar.
Sim, precisamos dar uma olhada no mini_racer.
Ficou curioso, por contexto, por que o JS é usado para renderizar Markdown?
Para garantir que o resultado seja exatamente o mesmo quando executado no navegador do cliente?
No desenvolvimento, um simples rails server já usa o Puma.
Sim. Agora que o wasm existe, pode ser uma saída, mas seria uma mudança muito grande manter a extensibilidade por meio de plugins como é hoje.
wasm definitivamente ficaria de fora aqui; o payload seria muito maior, há uma infinidade de problemas de segurança ao fazê-lo funcionar corretamente com CSPs (e preocupações com CORS). A implementação do markdown-it é espetacularmente rápida e extensível, permitindo uma infinidade de plugins e um enorme ecossistema existente.
Apenas mais um contexto sobre o mini_racer. Desde o dia 0 no Discourse, insistimos em um único pipeline para processar o markdown, o que eliminou completamente uma classe muito perigosa de bugs que experimentei no Stack Overflow, onde servidor e cliente falavam dialetos ligeiramente diferentes. Para o Discourse, isso é ainda mais importante porque plugins podem modificar o pipeline. Por exemplo:
é implementado em um plugin (análise de [])
Temos várias “melhorias na qualidade de vida” que obtemos ao usar o Unicorn e confiar no forking, veja:
Especificamente, monitoramos e gerenciamos um processo filho do Sidekiq a partir do processo mestre.
Mas… o Truffle não tem GIL, o Puma já está no Gemfile assim que o mini_racer estiver funcionando, poderíamos colaborar em uma configuração do Truffle que conserve memória, mantendo o Sidekiq e o Puma no mesmo processo. Ou as pessoas poderiam simplesmente iniciar um processo do Sidekiq manualmente. O Puma certamente pode funcionar; fazemos uso extensivo do Rack.hijack, mas isso já é implementado no Puma, Unicorn e Passenger.
mini_racer 0.6.3 agora funciona no TruffleRuby 