Mirror of forum.nim-lang.org

7692 :: I am confused. Javascript, WASM coroutine support ?

• lotib48819 (orginal) [2021-03-23T22:34:26+01:00] view original

  Hi. I do like Nim. It is beautiful and easy to develop. I just discovered it yesterday and I believe it is a RUST and GO killer. But I want to see if Nim can fit in my demands right now:

  1. Right now, can the coroutines work in Javascript or WASM (source compiled to C and then compiled to wasm)? Would they work automatically?
  2. Do the crypto nimble libraries that are C wrapped work compiled to javascript or to WASM or it is intended to write basic code right now?
  3. How can I define a different code block for the javascript to avoid for example os file system ?

  proc newLogger*(): Logger =

  var this = Logger()

  #CODE BLOCK FOR C

  createDir("./bin") createDir("./bin/logs") path = "./bin/logs/file.txt"

  #CODE BLOCK FOR JS

  do nothing path = ""

  Like in C language for UNIX/Windows macros. Any idea? So by doing this, my compilation for javascript won't throw errors for not having createDir defined.

---

• Yardanico (orginal) [2021-03-23T22:44:01+01:00] view original

  3)

  when not defined(js):
    # code for c, cpp, objc backends
  else:
    # code for the js backend
  Run

  4. Nim compilation times are usually quite fast unless you use a lot of concepts/converters/etc, but this will further be improved with incremental compilation which is in active development

---

• lotib48819 (orginal) [2021-03-23T22:48:55+01:00] view original

  hi Brotherhood of Nod.

  For 2. Is this the tutorial https://github.com/treeform/nim_emscripten_tutorial ?

---

• dsrw (orginal) [2021-03-24T06:15:58+01:00] view original

  1. Coroutines are definitely my #1 feature request for Nim, but for now they aren't well supported. The coro module is an unstable API that hasn't seen much attention recently. It works well under the arc/orc garbage collector, but has problems with the default gc, and probably won't ever work with the js backend. WASM/emscripten could be supported, but coro would need to be adapted to use something like fiber.h to do context switching.

  Nim's closure iterators are basically stackless coroutines and do work very well, but can only yield from within the body of the iterator. They also aren't supported by the js backend, but should work under wasm.

  For now, asyncdispatch and asyncjs is probably the best way to do concurrency.

  4. According to the nim compiler, my project + dependencies are 245,541 lines of code. It takes roughly 9.8 seconds to compile on my 2018 macbook pro.

---

• Araq (orginal) [2021-03-24T08:25:39+01:00] view original

  The coro module is an unstable API that hasn't seen much attention recently. It works well under the arc/orc garbage collector

  PRs are welcome. With orc becoming the default GC, coroutines are very interesting to look at again.

---

• lotib48819 (orginal) [2021-03-24T10:30:16+01:00] view original

  Is progressive compiling possible namely, if you change one line of code you need to wait again 9.8 seconds to compile ?

---

• ynfle (orginal) [2021-03-24T11:24:00+01:00] view original

  Incremental compilation is in active development

---

• Araq (orginal) [2021-03-24T11:29:46+01:00] view original

  it will dramatically reduce the compilation time ?

  It usually dramatically does reduce the compilation time as much time is spent in the C(++) backend part (plus all of its optimizers) and that result is cached effectively. Further improvements will come when incremental compilation will ship.

---