how to avoid mangling on names that need to be exported to js backend

[pietroppeter]

as a simple example I was trying to test the following:

import nimib

nbInit
nbCodeToJs:
  import p5

  proc newColor(): Color =
    let
      r = random() * 255
      g = random() * 255
      b = random() * 255

    result = color(r, g, b)

  proc setup() {.exportc.} =
    createCanvas(500, 500)
    frameRate(3)

  proc draw() {.exportc.} =
    background(newColor())
nbSave

apart the fact that library nimp5 is currently broken (see https://github.com/Foldover/nim-p5/issues/1), the js that is created has mangled names:

import
  p5

proc newcolor_452984937(): Color =
  let
    r = random() * 255
    g = random() * 255
    b = random() * 255
  result = color(r, g, b)

proc setup_452984938() {.exportc.} =
  createCanvas(500, 500)
  frameRate(3)

proc draw_452984939() {.exportc.} =
  background(newcolor_452984937())

in order for this library to work, we would need to be able to avoid the mangling for names draw and setup (so that further js compilation tagged with export does not mangel them any further).

[HugoGranstrom]

I feel like nbCodeToJs is falling apart like a house of cards :rofl: So the specific issue is that exportc isn't respected? Or is it mangled names in general?

[pietroppeter]

I feel like nbCodeToJs is falling apart like a house of cards 🤣

hey, we are using it! if it does not break it is not fun 😝

So the specific issue is that exportc isn't respected? Or is it mangled names in general?

I would expect that exportc will be respected but the js we generate from original code has a mangled name and one of the purpose of exportc would be to avoid further mangling so that an external library is able to guess the correct name.

[pietroppeter]

related: https://forum.nim-lang.org/t/9341

[HugoGranstrom]

hey, we are using it! if it does not break it is not fun :stuck_out_tongue_closed_eyes:

Haha true :rofl: If it wasn't for Karax we wouldn't have to mangle anything at all, but then we wouldn't have Karax :upside_down_face:

I would expect that exportc will be respected but the js we generate from original code has a mangled name and one of the purpose of exportc would be to avoid further mangling so that an external library is able to guess the correct name.

Okay, that I should be able to solve in the mangling logic :+1:

related: https://forum.nim-lang.org/t/9341

Worth noting is that as we can only have a single exported proc of each name, we are limited to 1 p5 instance per nimib page.

[pietroppeter]

Worth noting is that as we can only have a single exported proc of each name, we are limited to 1 p5 instance per nimib page.

indeed in p5js there is a different mechanism if one wants to have multiple canvas on the same page:

• https://stackoverflow.com/questions/37240287/can-i-create-multiple-canvas-elements-on-same-page-using-p5js
• https://github.com/processing/p5.js/wiki/Global-and-instance-mode

[HugoGranstrom]

Look at that, nice :)

[HugoGranstrom]

Just realized by looking at your bouncing ball blog post that {.push exportc.} also exists :sweat_smile: That's a totally different beast to try and parse. Would it be fine if we forced users to {.exportc.} all symbols individually for now?

[pietroppeter]

fixed by #125