Die Plattform fast_xor ist als :mri aufgeführt. Dieses Gem scheint jedoch C-Erweiterungen zu benötigen, ist aber nicht spezifisch für MRI: discourse/Gemfile at 0c7eaa57b26a22b0d0f85957ce0720be748d1fe6 · discourse/discourse · GitHub
Ich habe zudem bestätigt, dass es mit der neuesten Version von TruffleRuby funktioniert.
Könntest du die Plattform bitte auf :ruby aktualisieren?
Zur Referenz findest du hier eine Liste der Bedeutungen der verschiedenen Plattformen:
Sicher, ich habe mich darum gekümmert. Es gibt noch ein paar andere, bei denen ich mir unsicher bin – was soll ich damit machen? (byebug, ruby-prof, better_errors, rbtrace, gc_tracer, stackprof, memory_profiler)
Das heißt aber, wir sind bei Truffle komplett blockiert, bis mini_racer funktioniert, siehe:
https://github.com/oracle/truffleruby/issues/1827
Discourse ist nicht wirklich funktionsfähig, wenn man Markdown nicht auf dem Server in HTML umwandeln kann.
Danke, DEV: change platform mri to platform ruby on some gems · discourse/discourse@620c223 · GitHub sieht gut aus.
unicorn wird wahrscheinlich nicht auf TruffleRuby funktionieren, da es auf fork angewiesen ist, aber es installiert sich tatsächlich.
Kann Discourse stattdessen auf Puma laufen? Ist dafür eine Konfiguration erforderlich?
Es gibt noch ein paar andere, bei denen ich unsicher bin. Was soll ich mit ihnen machen? (byebug, ruby-prof, better_errors, rbtrace, gc_tracer, stackprof, memory_profiler)
Ja, all diese scheinen sehr MRI-spezifisch zu sein (bis sie verschiedene Backends unterstützen), also am besten vorerst als platforms: :mri angeben.
better_errors könnte funktionieren, aber binding_of_caller unterstützt TruffleRuby noch nicht.
Diese Gems scheinen zudem größtenteils Debugging- und Leistungstools zu sein, die für den Betrieb der Anwendung nicht unbedingt erforderlich sind.
Ja, wir müssen uns mini_racer ansehen.
Ich frage mich im Kontext, warum JavaScript zur Darstellung von Markdown verwendet wird.
Um sicherzustellen, dass das Ergebnis exakt dem entspricht, das im Client-Browser ausgeführt wird?
In der Entwicklung verwendet ein einfacher rails server standardmäßig Puma.
Ja. Seit es wasm gibt, könnte dies eine Lösung sein, aber es wäre eine sehr große Änderung, um die Erweiterbarkeit durch Plugins so zu erhalten, wie sie heute ist.
Wasm wäre hier definitiv keine Option; die Nutzlast wäre viel größer, und es gibt zahlreiche Sicherheitsprobleme im Zusammenhang mit der korrekten Ausführung unter CSPs (und CORS-Bedenken). Die Implementierung von markdown-it ist außerordentlich schnell und erweiterbar, was eine Vielzahl von Plugins und ein riesiges bestehendes Ökosystem ermöglicht.
Nur noch etwas mehr Kontext zu mini_racer: Von Anfang an bei Discourse haben wir auf eine einzige Pipeline zur Verarbeitung von Markdown bestanden. Das hat eine sehr unangenehme Klasse von Fehlern vollständig eliminiert, die ich bei Stack Overflow erlebt habe, bei denen Server und Client leicht unterschiedliche Dialekte sprachen. Für Discourse ist dies noch wichtiger, da Plugins die Pipeline anpassen können. Zum Beispiel:
wird in einem Plugin implementiert (Parsing von [])
Wir haben einige „Lebensqualitäts“-Funktionen, die wir durch die Nutzung von Unicorn und die Abhängigkeit vom Forking erhalten, siehe:
Insbesondere überwachen und verwalten wir einen Sidekiq-Kindprozess vom Master-Prozess aus.
Aber… Truffle hat keine GIL, Puma ist bereits in der Gemfile enthalten, sobald mini_racer funktioniert. Wir könnten an einer speichersparenden Truffle-Konfiguration zusammenarbeiten, die Sidekiq und Puma im selben Prozess hält. Oder Benutzer könnten einfach einen Sidekiq-Prozess manuell starten. Puma kann definitiv funktionieren; wir nutzen Rack.hijack ausgiebig, aber das ist bereits in Puma/Unicorn/Passenger implementiert.
mini_racer 0.6.3 funktioniert jetzt auf TruffleRuby 