更新 Gemfile fast_xor 平台到 :ruby

开发
1

fast_xor 平台被标记为 :mri。然而，该 gem 似乎需要 C 扩展，但并非 MRI 专用：discourse/Gemfile at 0c7eaa57b26a22b0d0f85957ce0720be748d1fe6 · discourse/discourse · GitHub

我也已确认它在最新的 TruffleRuby 上可以正常运行。

能否请您将平台更新为 :ruby？

供参考，以下是不同平台的含义列表：

5 个赞
2

好的，我已经处理好了。还有几个我不太确定的，该怎么处理它们？(byebug, ruby-prof, better_errors, rbtrace, gc_tracer, stackprof, memory_profiler)

不过，在 mini_racer 正常工作之前，我们完全被 truffleruby 卡住了，详情如下：

https://github.com/oracle/truffleruby/issues/1827

如果无法在服务器上把 Markdown 渲染成 HTML，Discourse 就无法真正正常运行。

5 个赞
3

谢谢，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。
这些 gem 也主要是调试或性能分析工具，似乎对于让应用运行起来并非必需。

是的，我们需要关注 mini_racer。

我想了解一下背景：为什么要用 JavaScript 来渲染 Markdown？
是为了确保结果与在客户端浏览器中运行时完全一致吗？

2 个赞
4

在开发环境中，简单的 rails server 命令会使用 Puma。

是的。现在既然 wasm 已经存在，这或许是一条出路，但要维持如今通过插件进行扩展的能力，这将是一项非常巨大的改动。

4 个赞
5

在这里使用 wasm 绝对不可行，负载会大得多，而且在配合 CSP（内容安全策略）运行时存在大量安全问题（以及 CORS 相关顾虑）。markdown.it 的实现极其快速且可扩展，支持大量插件，并拥有庞大的现有生态系统。

再补充一些关于 mini_racer 的背景信息。从 Discourse 创立之初，我们就坚持采用单一管道来处理 Markdown，这彻底消除了我在 Stack Overflow 经历过的某一类棘手 bug，即服务器端和客户端使用了略有不同的方言。对于 Discourse 而言，这一点更为重要，因为插件可以修改该管道。例如：

:arrow_backward: 是通过插件实现的（对 [] 的解析）

我们使用 Unicorn 并依赖其 fork 机制，获得了一些“提升生活质量”的功能，详见：

具体来说，我们在主进程中监控并管理 Sidekiq 子进程。

不过……Truffle 没有 GIL（全局解释器锁），一旦 mini_racer 正常工作，Puma 就会出现在 Gemfile 中。我们可以合作构建一个节省内存的 Truffle 配置，将 Sidekiq 和 Puma 保留在同一个进程中。或者，人们也可以手动启动 Sidekiq 进程。Puma 当然可以工作，我们广泛使用了 Rack.hijack，而该功能在 Puma、Unicorn 和 Passenger 中均已实现。

5 个赞
6

mini_racer 0.6.3 现在可以在 TruffleRuby 上运行了 :tada:

3 个赞