This KCL (intentionally causing errors) locks code mirror completely

[lf94]

// L-System KCL
// Zoo Corporation ⓒ 2024


// L-system 
// Note: it was most concise to encode productions directly in axioms.
// Change them as you need.

deg = pi()*2 / 360

fn setSketch = (state, _) => {
  return {
    depthMax: state.depthMax,
    depth: state.depth + 1,
    currentLength: state.currentLength,
    factor: state.factor,
    currentAngle: state.currentAngle,
    angle: state.angle,
    _: _
  }
}

fn setDepth = (state, _) => {
  return {
    depthMax: state.depthMax,
    depth: _,
    currentLength: state.currentLength,
    factor: state.factor,
    currentAngle: state.currentAngle,
    angle: state.angle,
    _:  state._
  }
}

fn setAngle = (state, _) => {
  return {
    depthMax: state.depthMax,
    depth: state.depth,
    currentLength: state.currentLength,
    factor: state.factor,
    currentAngle: _,
    angle: state.angle,
    _:  state._
  }
}

fn setLength = (state, _) => {
  return {
    depthMax: state.depthMax,
    depth: state.depth,
    currentLength: _,
    factor: state.factor,
    currentAngle: state.currentAngle,
    angle: state.angle,
    _:  state._
  }
}

fn Gt2 = (state) => { return setLength(state, state.currentLength * state.factor) }
fn Lt2 = (state) => { return setLength(state, state.currentLength / state.factor) }
fn Add = (state) => { return setAngle(state, rem(int(state.currentAngle - state.angle), 360)) }
fn Sub = (state) => { return setAngle(state, rem(int(state.currentAngle + state.angle), 360)) }

// Only necessary to get around recursion limitations...
fn X = (state, X) => {
  return if state.depth < state.depthMax {
    stateNext = state |> setDepth(%, state.depth + 1)

    // Produce
    // Note:if you need [ and ], just save state to a variable.
    stateNext
      |> F(%, F) |> Sub(%) |> F(%, F)
      |> Add(%) |> Add(%)
      |> F(%, F) |> Sub(%) |> F(%, F)
      |> setDepth(%, stateNext.depth - 1)

  } else {
    // Pass onto the next instruction
    state |> setSketch(%, angledLine({ angle: state.currentAngle, length: state.currentLength }, state._))
  }
}

// Only necessary to get around recursion limitations...
fn F = (state, F) => {
  
    // Pass onto the next instruction
    state |> setSketch(%, angledLine({ angle: state.currentAngle, length: state.currentLength }, state._))
  
}

fn LSystem = (args, axioms) => {
  return axioms({
    depthMax: args.iterations,
    depth: 0,
    currentLength: 1.0,
    factor: args.factor,
    currentAngle: 0,
    angle: args.angle,
    _: startSketchAt([0, 0]),
  })
}

LSystem({
  iterations: 2,
  factor: 1.36,
  angle: 60,
}, (_) => {
  result = _ |> F(%, F) |> Add(%) |> Add(%) |> F(%, F) |> Add(%) |> Add(%) |> F(%, F) 
  return result._
})

[jtran]

It's quite frustrating that any problem causes CodeMirror to lock up, meaning the user can't get out of the problematic state. #4240 is another example.

[lf94]

Holy f***ing hell. About 3-4 hours to debug. The problem here is the parser is reporting an out-of-bounds source range because it's interpreting text as bytes and not characters. The copyright symbol is technically 3 bytes, but 1 character, making the source range always off by 2. We think this is a data conversion issue created by the wasm code generator.

For example, the length going into the parser is 2691 (correct, as this is the number of characters), but the parser is returning an end range of 2693 (incorrect, as this is the total number of bytes in the code).

[jtran]

We think this is related to the transcoding of UTF-16 JS string to the UTF-8 Rust &str. See wasm_bindgen docs.

[lf94]

How the hell do we solve this one lol. Still around today.

[jtran]

The Rust side is computing UTF-8 byte offsets. JS is using this and treating it as code unit offsets. For most text, you can think of these as character offsets. But UTF-16 has surrogate pairs, so these are not quite characters. An emoji, for example, takes two indices in terms of str.slice() or string indexing. You need to be careful not to slice an emoji in half.

The most straight-forward way to map a single offset is to take the slice of the original string up to the offset you care about, transcode it, and see how long the result is. In JS, you could use TextDecoder to do this.

But for us, we have multiple offsets that we want to compute. Two for each source range, and we may have many source ranges, one for each warning or error. We don't allow multiple errors yet, but we will soon. We allow multiple parse errors and more recently, multiple runtime errors since merging #5431.

Say we have k offsets into a string of length n. If you used the above approach and naively wrapped it in a function, calling it k times, it would be O(kn), which is not great. We'd want to keep a running count and compute all k sequentially in byte-offset order, accumulating on the previous one, leading to O(n).

But before we implement anything, is there a completely different approach we could be using? I know we've explored them, but this is another reason to (re-)consider them.

[lf94]

https://simonsapin.github.io/wtf-8/