La piattaforma fast_xor è elencata come :mri. Tuttavia, questo gem sembra richiedere estensioni C, ma non è specifico per MRI: discourse/Gemfile at 0c7eaa57b26a22b0d0f85957ce0720be748d1fe6 · discourse/discourse · GitHub
Ho anche confermato che funziona sull’ultima versione di TruffleRuby.
Potreste aggiornare la piattaforma a :ruby?
Per riferimento, ecco un elenco dei significati delle diverse piattaforme:
Certo, me ne sono appena occupato. Ce ne sono un paio che ho lasciato perché non sono sicuro di cosa farne: cosa dovrei fare con loro? (byebug, ruby-prof, better_errors, rbtrace, gc_tracer, stackprof, memory_profiler)
Detto questo, siamo completamente bloccati su Truffle finché non riusciremo a far funzionare mini_racer come da:
https://github.com/oracle/truffleruby/issues/1827
Discourse non è davvero pienamente funzionale se non si può convertire il Markdown in HTML sul server.
Grazie, DEV: change platform mri to platform ruby on some gems · discourse/discourse@620c223 · GitHub sembra corretto.
unicorn probabilmente non funzionerà su TruffleRuby perché si affida a fork, ma in realtà si installa.
Discourse può essere eseguito su Puma invece? Serve qualche configurazione specifica?
Ci sono alcune altre gemme che ho lasciato perché non sono sicuro, cosa dovrei farne? (byebug, ruby-prof, better_errors, rbtrace, gc_tracer, stackprof, memory_profiler)
Sì, tutte sembrano molto specifiche per MRI (finché non inizieranno a supportare backend diversi), quindi è meglio impostarle come platforms: :mri per ora.
better_errors potrebbe funzionare, ma binding_of_caller non supporta ancora TruffleRuby.
Queste gemme sembrano essere principalmente strumenti di debug e prestazioni che non sembrano necessari per far funzionare l’applicazione.
Sì, dobbiamo esaminare mini_racer.
Mi chiedo, per contesto, perché viene usato JS per renderizzare il Markdown?
Per garantire che il risultato sia esattamente lo stesso di quando viene eseguito nel browser del client?
In fase di sviluppo, un semplice rails server utilizza Puma.
Sì. Ora che esiste wasm potrebbe essere una soluzione, ma sarebbe un cambiamento molto significativo per mantenerlo estendibile tramite plugin come lo è oggi.
wasm sarebbe decisamente fuori discussione in questo caso: il payload sarebbe molto più grande, ci sono un sacco di problemi di sicurezza legati al suo corretto funzionamento con le CSP (e le preoccupazioni relative al CORS). L’implementazione di markdown.it è straordinariamente veloce ed estendibile, consentendo un’ampia gamma di plugin e un enorme ecosistema già esistente.
Solo un po’ di contesto su mini_racer. Fin dal primo giorno, a Discourse abbiamo insistito per avere un’unica pipeline per elaborare il markdown; questo ha eliminato completamente una classe molto insidiosa di bug che ho sperimentato su Stack Overflow, dove server e client parlavano dialetti leggermente diversi. Per Discourse questo è ancora più importante perché i plugin possono modificare la pipeline. Ad esempio:
è implementato in un plugin (analisi di [])
Abbiamo diverse funzionalità “di qualità della vita” che otteniamo usando Unicorn e affidandoci al forking, come si può vedere qui:
In particolare, monitoriamo e gestiamo un processo figlio di Sidekiq dal processo principale.
Ma… Truffle non ha GIL, Puma è già presente nel Gemfile non appena mini_racer funziona. Potremmo collaborare per creare una configurazione di Truffle che conservi la memoria mantenendo Sidekiq e Puma nello stesso processo. Oppure, le persone potrebbero semplicemente avviare un processo Sidekiq manualmente. Puma può certamente funzionare; facciamo ampio uso di Rack.hijack, ma questa funzionalità è già implementata in Puma, Unicorn e Passenger.
mini_racer 0.6.3 ora funziona su TruffleRuby 