Платформа fast_xor указана как :mri. Однако этот gem, по-видимому, требует C-расширений, но не специфичен для MRI: discourse/Gemfile at 0c7eaa57b26a22b0d0f85957ce0720be748d1fe6 · discourse/discourse · GitHub
Я также подтвердил, что это работает на последней версии TruffleRuby.
Не могли бы вы обновить платформу до :ruby?
Для справки, вот список значений различных платформ:
Конечно, я только что занялся этим. Есть ещё несколько, которые я оставил, но не уверен насчёт них — что мне с ними делать? (byebug, ruby-prof, better_errors, rbtrace, gc_tracer, stackprof, memory_profiler)
Тем не менее, мы полностью заблокированы на Truffle, пока не заработает mini_racer, согласно:
https://github.com/oracle/truffleruby/issues/1827
Discourse не будет полноценно работать, если на сервере нельзя преобразовать Markdown в HTML.
Спасибо, DEV: change platform mri to platform ruby on some gems · discourse/discourse@620c223 · GitHub выглядит хорошо.
unicorn, скорее всего, не будет работать в TruffleRuby, так как он полагается на fork, но фактически он устанавливается.
Может ли Discourse работать на Puma? Требуется ли для этого какая-либо конфигурация?
есть ещё несколько, которые я оставил, но не уверен насчёт них. Что мне с ними делать? (byebug, ruby-prof, better_errors, rbtrace, gc_tracer, stackprof, memory_profiler)
Да, все они, похоже, очень специфичны для MRI (пока не начнут поддерживать другие бэкенды), поэтому пока лучше указать platforms: :mri.
better_errors может работать, но binding_of_caller пока не поддерживает TruffleRuby.
Эти гемы также кажутся в основном инструментами для отладки и профилирования производительности, которые, похоже, не нужны для запуска приложения.
Да, нам нужно посмотреть на mini_racer.
Интересно, в контексте, почему для рендеринга Markdown используется JS?
Чтобы гарантировать, что результат будет точно таким же, как при выполнении в браузере клиента?
В режиме разработки простой rails server использует Puma.
Да. Теперь, когда существует wasm, это может стать выходом, но это потребует очень больших изменений, чтобы сохранить возможность расширения через плагины, как это реализовано сегодня.
wasm в данном случае точно не подойдёт: размер полезной нагрузки был бы намного больше, возникло бы множество проблем с безопасностью при корректном запуске с учётом CSP (а также опасений по поводу CORS). Реализация markdown-it невероятно быстрая и расширяемая, что позволяет использовать множество плагинов и опирается на огромную существующую экосистему.
Вот ещё немного контекста о mini_racer. С самого начала работы над Discourse мы настаивали на едином конвейере для обработки markdown, что полностью устранило целый класс неприятных багов, с которыми я сталкивался в Stack Overflow, когда сервер и клиент использовали слегка разные диалекты. Для Discourse это ещё важнее, поскольку плагины могут модифицировать конвейер. Например:
реализуется в плагине (парсинг [])
Используя Unicorn и полагаясь на механизмы fork, мы получаем ряд «удобств для пользователя». Подробнее об этом можно прочитать здесь:
В частности, мы отслеживаем и управляем дочерним процессом Sidekiq из главного процесса.
Однако… в Truffle нет GIL, Puma уже присутствует в Gemfile после того, как mini_racer заработает. Мы могли бы совместно поработать над настройкой Truffle, экономящей память, при которой Sidekiq и Puma находились бы в одном процессе. Или же люди могли бы просто запустить процесс Sidekiq вручную. Puma определённо может работать; мы активно используем Rack.hijack, но эта функциональность уже реализована для Puma, Unicorn и Passenger.
mini_racer 0.6.3 теперь работает на TruffleRuby 