Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Rewatch: in-process bsc prototype

Ouverte
#8,659 2 commentaires 2 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Active
Stack technique
ocaml

Piste de recherche

Commencez par la réimplémentation d’OCaml Rewatch issue de #8653 et retracez la manière dont l’exécutable bsc est invoqué pour les étapes d’analyse et de compilation, y compris les builds de stdlib et des tests. Documentez les artefacts et l’état partagé impliqués, puis définissez un benchmark de prototype séquentiel ainsi qu’une recommandation concrète concernant la cible d’une implémentation ultérieure.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

Based on the OCaml rewatch reimplementation from #8653, we can prototype integrating the compiler directly into the rewatch executable to avoid having to spawn a bsc binary for each compilation step.

@cristianoc fed the prompt below into Fable, and I fed the same one into Astra.

I'll post the responses we got as separate comments. These can serve as a basis for further discussion.

We are porting Rewatch to OCaml as a drop-in for the Rust version. Next I want to see whether in-process bsc is worth it: stop spawning a bsc process per module, and ideally stop writing cmj/cmt (and maybe cmi) to disk at all.

Do not implement yet. Think this through with me.

Context:

  • A lot of build time is process creation and artifact I/O, not typechecking.
  • Integration might be >2x. I want a dirty prototype that measures that, even if it is incorrect and single-threaded.
  • The compiler has lots of global/shared mutable state (Clflags, Config.load_path, Env cache, Ident, Js_config, typechecker mutation, etc.). There are essentially no tests that reuse one compiler process across modules.
  • Getting rid of global state is probably much easier than the Rewatch port, but only if we know what to reset/isolate.
  • No multicore required for the prototype. Sequential in-process with no cm* writes may already be faster.
  • A real compiler service / parallel-from-one-process comes later.

Please:

  1. Survey how bsc is invoked today (parse vs compile), what it reads/writes (ast, cmi, cmj, cmt, js), and which globals would leak across compilations.
  2. Propose the smallest prototype that can give a real speedup signal on stdlib + tests (or a real project). What can stay on disk? What must be in memory? What must be reset between modules?
  3. Argue whether that prototype is the right next step, or whether something else is better (reset-and-reuse API, keep writing cmi only, compiler service still spawning-free but still on disk, etc.).
  4. Explicitly list what is likely to go well, what is likely to go wrong, and how we would get fooled by a misleading benchmark.
  5. Recommend a concrete goal we could later implement with /goal.
Langage dominant
OCaml
Étoiles
7.5k
Forks
484
Merge moyen
19 h 20 min
PR mergées (30 j)
96

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de rescript-lang/rescript

Toutes les issues de rescript-lang/rescript

Issues similaires

Plus d'issues Build System

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.