Update Gemfile fast_xor platform to :ruby

Dev
1

The fast_xor platform is listed as :mri. However, this gem appears to require C extensions but it is not specific to MRI: https://github.com/discourse/discourse/blob/0c7eaa57b26a22b0d0f85957ce0720be748d1fe6/Gemfile#L82

I have also confirmed this works on the latest TruffleRuby.

Could you please update the platform to :ruby?

For reference, here is a list of meanings for difference platforms:
https://bundler.io/man/gemfile.5.html#PLATFORMS

5 Likes
2

Sure I just too care of this there are a few others I left which I am unsure about, what should I do with them? (byebug, ruby-prof, better_errors, rbtrace, gc_tracer, stackprof, memory_profiler)

That said we are totally blocked on truffle till we get mini_racer working per:

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

Discourse is not really properly functional if you can not cook Markdown to HTML on the server.

5 Likes
3

Thanks, DEV: change platform mri to platform ruby on some gems · discourse/discourse@620c223 · GitHub looks good.

unicorn will likely not work on TruffleRuby because it relies on fork but actually it installs.

Can Discourse run on Puma instead, any configuration needed for that?

there are a few others I left which I am unsure about, what should I do with them? (byebug, ruby-prof, better_errors, rbtrace, gc_tracer, stackprof, memory_profiler)

Yes those all seem very MRI-specific (until they start supporting different backends), so best as platforms: :mri for now.
better_errors might work, but binding_of_caller does not support TruffleRuby yet.
These gems also seem mostly debugging/performance tools which don’t seem necessary to get the app running.

Yes, we need to look at mini_racer.

I wonder, for context, why is JS used to render Markdown?
To make sure it’s exactly the same result as when run in the client browser?

2 Likes
4

In development a simple rails server will use puma.

Yes. Now that wasm exists it may be a way out, but it would be a very big change to keep it as extensible by plugins as it is today.

4 Likes
5

wasm would definitely be off the table here, payload would be much bigger, there are tons of security issues around getting it to run right with CSPs (and CORS concerns), the implementation of markdown.it is spectacularly fast and extensible allowing for tons of plugins and a huge existing ecosystem.

Just some more context on mini_racer. From day 0 at Discourse we insisted on a single pipeline to cook markdown, this completely eliminated a very nasty class of bugs I have experienced at Stack Overflow where server and client spoke slightly different dialects. For Discourse this is even more important cause plugins can amend the pipeline. For example:

:arrow_backward: is implemented in a plugin (parsing of [])

We have quite a few “quality of life” features we get by using unicorn and relying on forking, see:

Specifically we monitor and manage a sidekiq child process from the master process.

But… truffle has no GIL, puma is already in the Gemfile once we have mini_racer working, we could collaborate on memory conserving truffle setup that keeps sidekiq and puma in the same process. Or people could just spawn a sidekiq process by hand. Puma can certainly work, we make use of Rack.hijack extensively but that is implemented across Puma/Unicorn/Passenger already.

5 Likes
6

mini_racer 0.6.3 works on TruffleRuby now :tada:

3 Likes