Compile JavaScript to WASM with no networking involved - just reading STDIN and writing to STDOUT

Abierto
  • ¿Algo no está bien?
#314 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
30/100
Tipo de issue
Documentación
Claridad
Necesita aclaración
Estado de actividad
Tranquilo
Stack tecnológico
javascript, wasm
Área
cli, compilers

Línea de trabajo

Empieza leyendo la documentación de StarlingMonkey y los puntos de entrada de starling.wasm y starling-raw.wasm; después, sigue cómo se exponen WIT y la entrada/salida estándar. Se considera terminado cuando estén documentadas las interfaces de I/O implementadas, el WIT mínimo y una ruta de compilación sin red para JavaScript genérico; el issue no menciona pruebas ni archivos fuente.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

I've built Native Messaging hosts using several JavaScript to WASM toolchains, or just executed the WASM inside of the JavaScript engine compiled to WASM in the case of QuickJS.

Here's the protocol and documentation published by Chrome, MDN, Edge, Opera, Safari https://github.com/guest271314/NativeMessagingHosts#native-messaging-documentation. In pertinent part

Chrome starts each native messaging host in a separate process and communicates with it using standard input (stdin) and standard output (stdout). The same format is used to send messages in both directions; each message is serialized using JSON, UTF-8 encoded and is preceded with 32-bit message length in native byte order. The maximum size of a single message from the native messaging host is 1 MB, mainly to protect Chrome from misbehaving native applications. The maximum size of the message sent to the native messaging host is 64 MiB.

Note, that the IPC communication is not a TTY.

Several examples of JavaScript compiled to WASM and/or embedded and executed within a JavaScript engine compiled to WASM can be found here

to the extent applicable and comparable to JavaScript or TypeScript,

I was referred to StarlingMonkey over here #general > Embedding JavaScript into QuickJS before compiling to WASM.

To be clear, I am not looking for "a" or "the" JavaScript to WASM toolchain; I'm actively testing, breaking, and vetting JavaScript to WASM toolchains and novel implementations, for research and comparative analysis purposes; without any biases or preferences for any. They all get tested until they break, witout rancor, and without exception or handicap.

Assume

  • I have basically zero experience writing WIT
  • There is zero networking involved in the JavaScript source code
  • I just need to read STDIN and write to STDOUT

Questions:

  • In node world there is process.stdin and process.stdout, and even readFileSync point to 0 or /dev/stdin or /proc/self/fd/0, and /dev/stdout or /proc/self/fd/1, respectively. STDOUT !== WHATWG Console's console. What are the specific I/O interfaces StarlingMonkey has implemented?

  • The Component Model has the WIT thing - it's own syntax and bassically an entire language itself. What is the minimal WIT that Component Model compilers expect just to read STDIN and write to STDOUT?

  • How to compile generic JavaScript that expects to done only read STDIN and write to STDOUT (neither specified in ECMA-262) - with absolutely no networking involved, no ServiceWorker-like fetch() handler at all, using StarlingMokey's starling.wasm or starling-raw.wasm?

Lenguaje dominante
C
Estrellas
295
Forks
62
Merge medio
1 d 17 h
PR fusionados (30 d)
16

Preparar el entorno

Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de bytecodealliance/StarlingMonkey

Todos los issues de bytecodealliance/StarlingMonkey

Issues similares

Más issues de C

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.